Batched RHS via Krylov.jl block methods (GMRES/MINRES)#1074
Merged
ChrisRackauckas merged 2 commits intoJul 5, 2026
Conversation
Krylov.jl provides block_gmres and block_minres, so those KrylovJL variants now accept matrix right-hand sides natively via BlockGmresWorkspace/BlockMinresWorkspace instead of erroring; the remaining Krylov methods (no block variants) keep the informative ArgumentError. The DefaultLinearSolver operator path's GMRES choice is un-gated accordingly, so `solve(LinearProblem(op, B))` with an operator A and matrix B now works out of the box. Co-Authored-By: Chris Rackauckas <accounts@chrisrackauckas.com> Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The resolved LinearAliasSpecifier.alias_A from init is now stored on the LinearCache. When the user permitted overwriting A, the dense LUFactorization refactorization path (after cache.A = X) runs lu!(cache.A) in place instead of paying lu's O(n^2) copy on every refactorization. Also updates the stale batch testset that still expected KrylovJL_GMRES to reject matrix right-hand sides: block GMRES/MINRES support made that path solve instead of throw, so it now asserts correct batched solutions and keeps the informative-error checks on the methods without block variants. Co-Authored-By: Chris Rackauckas <accounts@chrisrackauckas.com> Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follow-up to #1072, answering the review question "Krylov.jl does not support batched solves?" — it does, for a subset:
block_gmresandblock_minres.KrylovJL_GMRES/KrylovJL_MINRESwith a matrixbnow buildBlockGmresWorkspace/BlockMinresWorkspaceand solve natively throughkrylov_solve!(M/N preconditioners, restart, tolerances all pass through; solution read from.X).ArgumentError, with the message updated to point at the block-capable options.DefaultLinearSolveroperator-path GMRES choice is un-gated, sosolve(LinearProblem(op, B))with a matrix-free operator and matrixBworks out of the box.Verified locally (Julia 1.12): block GMRES ≈
A\B(Success, right shape) for dense and viaFunctionOperatordefault; block MINRES on symmetric; cache reuse with swappedB;KrylovJL_CGstill errors informatively.Also observed while integrating downstream (ExponentialUtilities#236): dense
LUFactorizationrefactorization always copies A (fact = lu(A, check = false)in the non-sparse branch of itssolve!), making cache reuse O(n²)-allocating;GenericLUFactorizationis the allocation-free option today. An opt-in in-place dense refactorization (honoringalias_A) would let LAPACK-speed LU be allocation-free too — happy to add it here or separately.🤖 Generated with Claude Code